Method and Apparatus for Providing Emergency Codes to a Mobile Device

ABSTRACT

A method at a user equipment for obtaining emergency codes using a non-Third Generation Partnership Project (3GPP) network, the method including sending a request message to a network node, the request message containing an indication; and receiving, at the user equipment, a response message, the response message including at least one mobile country code (MCC), and the response message indicating an emergency number, type or category information, wherein the emergency number, type or category information is associated with the at least one MCC, and wherein the at least one MCC indicates a portion of a Public Land Mobile Network (PLMN) code to which the emergency number, type or category information applies.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.17/883,109, filed Aug. 8, 2022, now U.S. Pat. No. 11,743,707, issued onAug. 29, 2023, which is a continuation of U.S. application Ser. No.17/013,304, filed Sep. 4, 2020, now U.S. Pat. No. 11,445,350, issued onSep. 13, 2022, which claims the benefit of U.S. application Ser. No.16/696,901, filed Nov. 26, 2019, now U.S. Pat. No. 10,771,952, issued onSep. 8, 2020, which claims the benefit of U.S. application Ser. No.16/220,966, filed Dec. 14, 2018, now U.S. Pat. No. 10,499,234, issued onDec. 3, 2019, which claims the benefit of U.S. application Ser. No.15/714,497, filed Sep. 25, 2017, now U.S. Pat. No. 10,165,432, issued onDec. 25, 2018, which claims the benefit of U.S. Provisional ApplicationNo. 62/481,053, filed on Apr. 3, 2017, the entire contents of which arehereby expressly incorporated by reference herein in their entireties.

FIELD OF THE DISCLOSURE

The present disclosure relates to emergency calling, and in particularrelates to identification of appropriate emergency calling numbers andcategories or types.

BACKGROUND

When a third generation partnership project (3GPP) device or userequipment (UE) desires to access an Evolved Packet Core (EPC)/EvolvedPacket System (EPS) core via an access network that is not a 3GPPdefined access network (where a 3GPP access network could be a GlobalSystem For Mobile Communications (GSM) EDGE Radio Access Network(GERAN), Universal Terrestrial Radio Access Network (UTRAN) or EvolvedUniversal Mobile Telecommunications Service (UMTS) Terrestrial RadioAccess Network (E-UTRAN)), the UE may need to select and then establisha connection with an Wireless Local Area Network (WLAN). Various aspectsand predicates exist for a UE to access an WLAN and obtain a list ofemergency codes that can be trusted. These may include trusted access,non-trusted access, Extensible Authentication Protocol (EAP), ProtocolConfiguration Options (PCO), Voice over Wi-Fi, UE detected emergencycalls, Dynamic Host Configuration Protocol (DHCP), WLAN Access NetworkQuery Protocol (WLAN ANQP), Fifth generation (5G) network, emergencynumbers via WLAN and policy using a Non-Access Spectrum (NAS) indicatorvia a 3GPP Access Network (AN), or Emergency numbers via 3GPP AccessNetwork.

Networks need to provide emergency numbers and types or categories (e.g.fire, ambulance, police, mountain rescue, etc.) for which “UE detectedemergency calls” are supported by the network or public land mobilenetwork (PLMN) via a (Trusted or untrusted) WLAN. Different countriessupport different emergency numbers and types and categories, and “UEdetected emergency calls”. Further, even in the same country, differentPLMNs may support different “UE detected emergency calls”.

A UE connected to different PLMNs via 3GPP access and WLAN access may beconfigured by both (i.e. first and second) PLMNs with emergency callnumbers and types or categories.

When the UE has been configured with a second PLMN's emergency numbersand types or categories via WLAN, and the UE uses these to initiate a“UE detected emergency call” via, for example, 3GPP access where theserving network is a first PLMN, then first PLMN may receive a “UEdetected emergency call” for a type/category for which it hasn'tconfigured its network.

Instead, the first PLMN would have expected to receive a normal call.The normal call request message would include dialed digits. The networkwould then parse the dialed digits and possibly route the call to thecorrect public safety answering point (PSAP) based on the dialed digits.A “UE detected emergency call” request message, however, need notinclude dialled digits.

Further, when emergency numbers are provided to a UE via WLAN, they maybe provided before a UE is connected to a PLMN. When more than one PLMNis available, there is no mapping of emergency numbers to those PLMNs.Alternatively, the entity providing emergency numbers that are providedto a UE via WLAN may not know or may not be able to predict to whichPLMN the UE will successfully connect via WLAN. An example of such anentity is an ANQP server or an Access Point (AP).

A fifth generation (5G) network can have many network slices, includingbut not limited to Internet of Things (IoT), voice, among others. Eachslice may have its own set of emergency numbers. For example, one numbermay be 911 for voice and a second number may be 811 for automated IoTdevices. There is no way for a multi-purpose device to know whichemergency number to use for a particular slice.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will be better understood with reference to thedrawings, in which:

FIG. 1 is a data flow diagram showing EAP SIM;

FIG. 2 is a data flow diagram showing DHCP message flow;

FIG. 3 is a block diagram showing WLAN access network query protocol;

FIG. 4 is a block diagram of a non-roaming architecture for 5G corenetwork with non-3GPP access;

FIG. 5 is a data flow diagram showing a general procedure for receipt ofshort codes in accordance with one embodiment;

FIG. 6 is a data flow diagram showing EAP signalling for short codeconfiguration;

FIG. 7 is a data flow diagram showing initial registration via anuntrusted non-3GPP access;

FIG. 8 is a block diagram of a simplified electronic device capable ofbeing used with the methods and systems herein according to oneembodiment; and

FIG. 9 is a block diagram of a mobile device according to oneembodiment.

FIGS. 10A-10E represent changes to the definition of the genericcontainer within 3GPP TS 24.302, shown in bold and underlining;

FIGS. 11A-11D represent example changes to the Wi-Fi Alliance Hotspot2.0 (Release 2) Technical Specification version 1.2.5, shown in bold andunderlining;

FIGS. 12A-12H show one example potential modification to a specificationin bold and underlining, section numbers and references are those inthat specification;

FIGS. 13A-13C are proposed modifications to RFC 2132;

FIGS. 14A and 14B show in bold (item 7) changes that adds text to 3GPPTS 23.501; and

FIG. 15 is proposed modifications to 3GPP TS 24.008.

DETAILED DESCRIPTION

The present disclosure provides a method at a user equipment forobtaining emergency codes, the method comprising: sending a requestmessage to a network node, the request message containing an indication;and receiving, at the user equipment, a response message, the responsemessage including one or more lists of emergency numbers, wherein theone or more lists of emergency numbers are each associated with acountry code.

The present disclosure further provides user equipment configured toobtain emergency codes, the user equipment comprising: a processor; anda communications subsystem, wherein the user equipment is configured to:send a request message to a network node, the request message containingan indication; and receive a response message, the response messageincluding one or more lists of emergency numbers, wherein the one ormore lists of emergency numbers are each associated with a country code.

The present disclosure further provides a non-transitory computerreadable medium for storing instruction code for obtaining emergencycodes, where the instruction code, when executed by a processor of auser equipment causes the user equipment to: send a request message to anetwork node, the request message containing an indication; and receivea response message, the response message including one or more lists ofemergency numbers, wherein the one or more lists of emergency numbersare each associated with a country code.

The present disclosure further provides a method at a user equipmentcomprising: sending a request message to a network node, the requestmessage containing an indication; and receiving, at the user equipment,a response message, the response message including a uniform resourcename including an empty emergency number list along with a country code.

The present disclosure further provides a user equipment comprising: aprocessor; and a communications subsystem, wherein the user equipment isconfigured to: send a request message to a network node, the requestmessage containing an indication; and receive a response message, theresponse message including a uniform resource name including an emptyemergency number list along with a country code.

The present disclosure further provides a non-transitory computerreadable medium for storing instruction code which, when executed by aprocessor of a user equipment, causes the user equipment to: send arequest message to a network node, the request message containing anindication; and receive a response message, the response messageincluding a uniform resource name including an empty emergency numberlist along with a country code.

In accordance with the embodiments described below, Table 1 provides oneexample definition of the terminology used herein:

TABLE 1 Terminology Term Brief Description RPLMN Registered PLMN, thisis the PLMN that the UE has successfully attached to. It can be eitherVPLMN or a HPLMN. VPLMN This is a PLMN whose Mobile Country Code, MobileNetwork Code does not match the MCC, MNC stored in either EF_(IMSI) orEF_(EHPLMN) both of which are specified in 3GPP TS 31.102,“Characteristics of the Universal Subscriber Identity Module (USIM)application”, v.14.2.0, March 2017. HPLMN This is a PLMN whose MobileCountry Code, Mobile Network Code does match the MCC, MNC stored ineither EF_(IMSI) as specified in 3GPP TS 31.102. Other potential HPLMNscan be EHPLMNs and EPLMNs. EHPLMN This is a PLMN that is equivalent tothe HPLMN. The identities are stored in EF_(EHPLMN) which is specifiedin 3GPP TS 31.102 EPLMN Equivalent PLMN. These are PLMNs that areequivalent to the RPLMN. The identities are received in an Attach Acceptfrom the RPLMN. Network The Network Slice is a complete logical networkthat comprises a set slice of network functions and correspondingresources necessary to provide certain network capabilities and networkcharacteristics. It includes both 5G-AN and 5G CN. A Network SliceInstance (NSI) is the Instantiation of a Network Slice, i.e. a deployedset of network functions delivering the intended Network Slice Servicesaccording to a Network Slice Template A Network Slice provides a logicalnetwork that may include: the Core Network control plane and user planeNetwork Functions, the 5G Radio Access Network the Non-3GPP InterworkingFunction (N3IWF) functions to the non- 3GPP Access Network. Networkslices may differ for supported features and network functionsoptimisations. The operator may deploy multiple Network Slice instancesdelivering exactly the same features but for different groups of UEs,e.g. as they deliver a different committed service and/or because theymay be dedicated to a customer. A single UE can simultaneously be servedby one or more Network Slice instances via a 5G-AN. The Access andMobility Management function (AMF) instance serving the UE logicallybelongs to each of the Network Slice instances serving the UE, i.e. thisAMF instance is common to the Network Slice instances serving a UE. TheAMF discovery and selection for the set of slices for a UE is triggeredby the first contacted AMF in a registration procedure and it may leadto change of AMF. SMF discovery and selection is initiated by the AMFwhen a Session Management message to establish a PDU session is receivedfrom the UE. The Network Repository Function (NRF) is used to assist thediscovery and selection tasks. A PDU session belongs to one and only onespecific Network Slice instance per PLMN. Different Network Sliceinstances do not share a PDU session, though different slices may haveslice-specific PDU sessions using the same Data Network Name (DNN).5.15.2 Identification and selection of a Network Slice: The S- NSSAI andthe NSSAI An S-NSSAI (Single Network Slice Selection Assistanceinformation) identifies a Network Slice. An S-NSSAI is comprised of: ASlice/Service type (SST), which refers to the expected Network Slicebehaviour in terms of features and services; A Slice Differentiator(SD), which is optional information that complements the Slice/Servicetype(s) to allow further differentiation for selecting an Network Sliceinstance from the potentially multiple Network Slice instances that allcomply with the indicated Slice/Service type. This information isreferred to as SD. N3IWF A 5G function that can be equated to an ePDG.AMF Access and Mobility Management function, a 5G term similar to anMME.

As provided above, various aspects and predicates exist for a UE toaccess a WLAN and obtain a list of emergency codes that can be trusted.Examples of such aspects and predicates are provided below.

Trusted Access

Trusted access may also be known as S2a access. The UE performs WLANAccess Authentication and Authorization (AAA). In this step the UE mayreceive a trust indicator from the network in the EAP signalling that isused as part of the Authentication and Authorisation step. If the trustindicator indicates the network is trusted, the UE uses trusted networkaccess procedures. For example, in one case such trusted network accessprocedures are described in 3GPP Technical Specification (TS) 24.302,“Architecture Enhancements For Non-3GPP Accesses”, as for exampleprovided in v.14.3.0, March 2017.

Non-Trusted Access

Non-trusted access may also be known as S2b access. Once the UE hasconnected to a WLAN and IP connectivity has been established on theconnected-to WLAN (e.g. an IP address has been obtained e.g. usingDHCP), then the UE sets up an Internet Protocol Security (IPsec) tunnelto a network function or network element called an evolved packet datagateway (ePDG). The ePDG terminates/acts as an end point to the IPsectunnel and selects a Packet Data Network Gateway (P-GW), for examplebased on a parameter provided by the UE.

In connecting to the WLAN and before establishing IP connectivity, theUE may perform WLAN Access Authentication and Authorisation using EAPsignalling, as described below, or by other means such as, for example,splash screens or a captive portal, a Wi-Fi Alliance Passpoint,pre-shared key, username/password which may for example use aAAA/RADIUS/Diameter server, among other options.

EAP

The Extensible Authentication Protocol, as the name suggests, is anextensible authentication framework. It provides the necessary tools toincorporate other authentication schemes into the basic messagingstructure. There are numerous different EAP mechanisms defined. EAP is,for example, described in the Internet Engineering Task Force (IETF)Request for Comments (RFC) 3748, “Extensible Authentication Protocol(EAP)”, June 2004. A diagrammatic view of how the EAP framework can beused in a cellular device can be seen in FIG. 1 .

Reference is now made to FIG. 1 . In the embodiment of FIG. 1 , a UE 110includes a mobile equipment (ME) as well as a SIM. UE 110 communicateswith access point (AP) 112, for example utilizing an 802.1x Service SetIdentifier (SSID).

Further, access point 112 may communicate with network elements,including DHCP Sever 114, AAA Server 116, WLAN Access Gateway (WAG) 118,and Home Location Registry (HLR) 120. DHCP Server 114 will be understoodby those in the art to be a note implementing DHCP protocol. Similarly,AAA Server 116 will be understood by those in the art to be a noteimplementing AAA protocol.

Registration starts by an Extensible Authentication Protocol (EAP)Req/Resp ID message 122 being sent between the UE 110 and AP 112.Message 122 may include an identifier such as the International MobileSubscriber Identity (IMSI) which may be associated with a realm.

AP 112 then forwards message 122 to AAA 116, as shown by message 124.

On receipt of message 124, the AAA 116 and AP 112 exchange an EAPReq/Resp SIM Start message 130 which may include a nonce and a versionsupport.

AP 112 may then forward message 130 to UE 110, shown as message 132.

AAA 116 may further send a Mobile Application Part (MAP) SendAuthentication Information (SAI) (IMSI) message 134 to HLR 120.

Based on message 134, HLR 120 generates keys, as shown by block 140.

Further, AAA 116 may calculate the AT_MAC=HMAC_SHA1 (EAP Packet |Nonce),as shown at block 142.

HLR 120 provides the keys back to AAA 116 as a MAP SAI Ack (SRES, RAND,Kc) message 150.

AAA 116 then provides an EAP Req/Resp SIM Challenge message 152,including the RAND and the AT_MAC calculator at block 142 to AP 112.

Message 152 is then forwarded to UE 110 as message 154.

The SIM on UE 110 may then calculate encryption parameters, as shown byblock 160 and may provide a response 170 back to AP 112. The response170 may include the AT_MAC_SRES.

The response 170 is then forwarded by AP 112 to AAA 116, as shown bymessage 172.

On checking the response 172, AAA 116 may then send an EAP Req/RespSuccess message 174 to AP 112. Message 174 may include a key (K).

Message 174 is then forwarded by AP 112 to UE 110 as message 176 in theembodiment of FIG. 1 .

Subsequently, encrypted traffic may be passed between UE 110 and AP 112using K as the WPA/TKIP Key, as shown with arrow 180.

UE 110 may then provide a DHCP Request/Response 182 to DHCP 114.

UE 110 may then provide IP Packet 184 to WAG 118.

Subsequently, a Login d/1 Profile 190 may be exchanged between WAG 118and AAA 116.

3GPP defines three EAP methods that can be used in a UE. A first isEAP-Authentication and Key Agreement (AKA), described for example inIETF RFC 4187, “Extensible Authentication Protocol Method for 3rdGeneration Authentication and Key Agreement (EAP AKA)”, January 2006. Asecond is EAP-Subscriber Identity Module (SIM), described for example inIETF RFC 4186, “Extensible Authentication Protocol Method for GSMSubscriber Identity Modules (EAP-SIM)”, January 2006. A third isEAP-AKA′, described for example in IETF RFC 5448, “Improved ExtensibleAuthentication Protocol Method for 3rd Generation Authentication and KeyAgreement (EAP-AKA)”, May 2009.

The EAP-SIM authentication mechanism has been generally considered bythe experts in the subject area to have been compromised and thereforeno longer safe to use, so only EAP-AKA and EAP-AKA′ are typically usedto access an EPC/EPS core network.

Once EAP authentication has been successful, the UE can then establishIP connectivity from the Wi-Fi network e.g. using DHCP. Once IPconnectivity has been established on the Wi-Fi network, an ePDG can thenbe selected.

Within the EAP procedure, it is possible to provide configurationparameters to the UE, which includes PCO as described below.

Protocol Configuration Options (PCO)

PCO is a general name given to a capability first used in GSM PacketRadio Service (GPRS). It allows a device, via several indicators(wherein an indicator can consist of one or more bits or even theabsence of one or more bits in a message), to indicate to the networksome information that the UE requires. The network would then respondback with information pertaining to the requested information and/orinformation not requested. The request and response mechanism is calledPCO.

This capability was later extended to UTRAN and Long Term Evolution(LTE)/E-UTRAN, and then also WLAN networks via EAP signalling connectionestablishment. Some data types a UE can request and be provided with aredescribed, for example, in 3GPP TS 24.008, “Mobile radio interface Layer3 specification; Core network protocols; Stage 3”, v. 14.3.0, March2017, subsection 10.5.6.3. Examples include Proxy Call Session ControlFunction (P-CSCF) addresses, Network Based IP Flow Mobility (NBIFOM)mode, IP flow mobility (IFOM) support, among other options.

PCO is defined in 3GPP TS 24.008, subclause 6.1.3.7, and further in 3GPP24.301, “Non-Access-Stratum (NAS) protocol for Evolved Packet System(EPS); Stage 3”, v.14.3.0, March 2017, subclause 6.6.1 and 3GPP TS24.302, subclauses 6.9 and 6.4.3.5.2. In 3GPP accesses (e.g. GERAN,UTRAN, E-UTRAN) the PCO information comes from a Gateway GPRS SupportNode (GGSN), or P-GW. The GGSN or P-GW can be located in the VisitedPublic Land Mobile Network (VPLMN) or Home Public Land Mobile Network(HPLMN). The GGSN or P-GW may be configured with the information (e.g.via operator O&M procedures) or the information may be obtained by someother means.

Voice Over Wi-Fi

Prior to the UE attempting a Voice over WiFi (VoWiFi) call, the devicemay have selected an ePDG to access the EPC network that will connect tothe IP Multimedia System (IMS) network. After ePDG selection has beenperformed, the UE then creates a tunnel to the selected ePDG, andeventually performs an IMS/SIP REGISTRATION, as for example described in3GPP TS 24.229, “IP multimedia call control protocol based on SessionInitiation Protocol (SIP) and Session Description Protocol (SDP); Stage3”, v.14.3.1, March 2017. The registration is performed with an IMSnetwork that connects to the EPC network. After the IMS REGISTRATION hascompleted, the UE can make a voice call at any time. When the call isdetected to be an emergency call, dedicated emergency call proceduresmay be executed. The dedicated emergency call procedures differ fromprocedures for calls not detected to be emergency calls. At the UE, twotypes emergency call procedures exist: UE detected emergency calls andnetwork detected emergency calls”.

UE Detected Emergency Calls

It is possible for a UE to detect, e.g. based upon either digits enteredor selected or a session initiation protocol (SIP)/telephony (TEL)uniform resource identifier (URI) being selected, that a call is anemergency call. This detection is performed by configuring the UE, e.g.with those numbers. This configuration can be performed either:

-   -   a) within the mobile equipment (ME) or universal subscriber        identity module (USIM)    -   b) by the access network providing them.        -   a. In Attach Accept (e.g. see 3GPP TS 24.008 or 3GPP TS            24.302) if using 3GPP access; or        -   b. Via domain name system (DNS) or access network query            protocol (ANQP), as described below, if using non 3GPP            access.

It is possible that the UE obtains this provisioning information frommany sources. In such case the dynamic information takes precedence. Ifdynamic information is received from both 3GPP and non 3GPP accessnetworks, requirements have been defined that a registered PLMN (RPLMN)can provide a policy to indicate if both sets of provisioninginformation (e.g. numbers and types) can be used.

Network Detected Emergency Calls

It is possible that the network detects the call is an emergency call.The network may inform the UE and the UE may initiate an emergency callin response to the network informing the UE.

Dynamic Host Configuration Protocol (DHCP)

DHCP is used in an IP network in order to dynamically configure networkhosts with data/parameters, such as IP addresses, DNS servers, defaultgateway, among other options. The message flow for DHCP is shown in FIG.2 .

As seen in FIG. 2 , a client 210 communicates with a server 212.

In message 220, the DHCP client 210 (which may reside or be hosted on aUE) broadcasts a Discover message to the connected-to network (e.g.sends it to an IPv4 address of 255.255.255.255).

One or more DHCP servers 212 may respond to the client with a DHCP Offermessage 222, which contains one or more parameters, such as an IPaddress.

In response to one of the DHCP Offers the client 210 receives, theclient 210 broadcasts a DHCP Request message 224 accepting the chosenDHCP Offer, and in this broadcast message there may be included someparameters requesting further configuration data/parameters.

In response to the received DHCP Request that the DHCP Server who sentthe associated DHCP Offer receives, the DHCP Server sends a DHCPAcknowledgement 226 (also known as a DHCP ACK), which may contain suchinformation as lease duration and any other configurationdata/information that the client may have requested. The DHCP Client,upon receiving the DHCP Acknowledge, configures the host (e.g. the UE)appropriately with the received parameters for the interface upon whichthe DHCP transaction took place.

Some basic DHCP options are defined by the IETF in IETF RFC 2132 [15],and further options are specified in further IETF specifications.

DHCP can be used in IPv4 networks and IPv6 networks, in which caseDHCPv4 and DHCPv6 nomenclature is used. DHCPv6 has the following messagenames in place of those in FIG. 2 above:

-   -   a) Solicit    -   b) Advertise    -   c) Request    -   d) Reply

WLAN ANQP (Access Network Query Protocol)

An example architecture of the WLAN system is shown in FIG. 3 . The IEEE802.11 Access Network Query Protocol is one example of an advertisementprotocol transported between mobile stations (STAs 310) and accesspoints (APs 320). The STA is the equivalent of a UE.

In the embodiment of FIG. 3A Generic Advertisement Service (GAS) 340 maybe provided between STA 310 and AP 320. For example, STA 310 receives abeacon 322 from AP 320. Further STA 310 may send a probe 312 and listenfor a probe response 326.

ANQP operates as a simple query and response protocol that is used by amobile device to discover a range of information 330 from an “AccessNetwork” (AN) server. This AN server is either co-located with an AP oris located within the Local Area Network (LAN), which is the layer 2network to which the AP is connected.

ANQP 350 allows a mobile device (e.g. STA, UE) to determine theproperties of the LAN before starting or at any time after theassociation procedure.

Information obtained through ANQP 350 can include: network identifiers,roaming relationships, supported security methods (IEEE 802.1X andweb-based authentication), available service providers, among otheroptions. This enables ANQP to be a very powerful protocol capable ofdiscovering information about WLANs, e.g. prior to the mobile deviceestablishing network connectivity.

Currently there are more than 20 individual ANQP-elements defined inIEEE 802.11 and various Wi-Fi Alliance programs (e.g. Hotspot 2.0), eachone capable of retrieving different information (reports) from the LAN,for example:

-   -   a) AP Location    -   b) AP Venue Name    -   c) Service Provider availability

To discover each ANQP-element, the UE (STA) sends an ANQP Request to theAN server via an AP with an integer identifier (Info ID) correspondingto the desired information report. The AN server AP then responds, viathe AP, with an ANQP-element containing that information report. The ANserver may also discover the required information from either the WLANor an external network to which it is attached.

5G Network

FIG. 4 shows a non-roaming architecture for a 5G core network withnon-3GPP access.

Within the 5G deployed network, various functions are provided in the3GPP TS 23.501, “System Architecture for the 5G System”, as for exampleprovided in v. 0.3.0, February 2017. Example functions are provided inTable 2 below. The functions of Table 2 are virtualized; hence anoperator may have many different “network slices” deployed. Networkslices, to be further known as “slices” can perform different functionse.g. support voice based services, IoT services etc. PLMNa may deployedslices A and B while PLMN B may deploy slices A and C. Devices need tosupport multitude of capabilities or slices to be able to roam

TABLE 2 5G definitions from 3GPP TS 23.501 6 Network Functions 6.1General 6.2 Network Function Functional description 6.2.1 AMF The Accessand Mobility Management function (AMF) includes the followingfunctionality. Some or all of the AMF functionalities may be supportedin a single instance of a AMF: Termination of RAN CP interface (N2).Termination of NAS (N1), NAS ciphering and integrity protection.Registration management. Connection management. Reachability management.Mobility Management. Lawful intercept (for AMF events and interface toLI System). Transparent proxy for routing SM messages. AccessAuthentication. Access Authorization. Security Anchor Function (SEAF).It interacts with the AUSF and the UE, receives the intermediate keythat was established as a result of the UE authentication process. Incase of USIM based authentication, the AMF retrieves the securitymaterial from the AUSF. Security Context Management (SCM). The SCMreceives a key from the SEAF that it uses to derive access-networkspecific keys. NOTE: Regardless of the number of Network functions,there is only one NAS interface instance per access network between theUE and the CN, terminated at one of the Network functions thatimplements at least NAS security and mobility management. In addition tothe functionalities of the AMF described above, the AMF may include thefollowing functionality to support non-3GPP access networks: Support ofN2 interface with N3IWF. Over this interface, some information (e.g.3GPP cell Identification) and procedures (e.g. Hand-Over related)defined over 3GPP access may not apply, and non-3GPP access specificinformation may be applied that do not apply to 3GPP accesses. Supportof NAS signalling with a UE over N3IWF. Some procedures supported by NASsignalling over 3GPP access may be not applicable to untrusted non-3GPP(e.g. Paging) access. Support of authentication of UEs connected overN3IWF. Management of mobility and authentication/security contextstate(s) of a UE connected via non-3GPP access or connected via 3GPP andnon-3GPP accesses simultaneously. Support as described in clause 5.3.2.3a co-ordinated RM management context valid over 3GPP and Non 3GPPaccesses. Support as described in clause 5.3.3.4 dedicated CM managementcontexts for the UE for connectivity over non-3GPP access. NOTE: Not allof the functionalities are required to be supported in an instance of anetwork slice. 6.2.2 SMF The Session Management function (SMF) includesthe following functionality. Some or all of the SMF functionalities maybe supported in a single instance of a SMF: Session Management e.g.Session establishment, modify and release, including tunnel maintainbetween UPF and AN node. UE IP address allocation & management (incloptional Authorization). Selection and control of UP function.Configures traffic steering at UPF to route traffic to properdestination. Termination of interfaces towards Policy control functions.Control part of policy enforcement and QoS. Lawful intercept (for SMevents and interface to LI System). Termination of SM parts of NASmessages. Downlink Data Notification. Initiator of AN specific SMinformation, sent via AMF over N2 to AN. Determine SSC mode of a session(for IP type PDU session). Roaming functionality: Handle localenforcement to apply QoS SLAs (VPLMN). Charging data collection andcharging interface (VPLMN). Lawful intercept (in VPLMN for SM events andinterface to LI System). Support for interaction with external DN fortransport of signalling for PDU session authorization/authentication byexternal DN. NOTE: Not all of the functionalities are required to besupported in an instance of a network slice. 6.2.3 UPF The User planefunction (UPF) includes the following functionality. Some or all of theUPF functionalities may be supported in a single instance of a UPF:Anchor point for Intra-/Inter-RAT mobility (when applicable). ExternalPDU session point of interconnect to Data Network. Packet routing &forwarding. Packet inspection and User plane part of Policy ruleenforcement. Lawful intercept (UP collection). Traffic usage reporting.Uplink classifier to support routing traffic flows to a data network.Branching point to support multi-homed PDU session. QoS handling foruser plane, e.g. packet filtering, gating, UL/DL rate enforcement UplinkTraffic verification (SDF to QoS flow mapping). Transport level packetmarking in the uplink and downlink. Downlink packet buffering anddownlink data notification triggering. NOTE: Not all of the UPFfunctionalities are required to be supported in an instance of userplane function of a network slice. . . . 6.2.7 UDM The Unified DataManagement (UDM) supports the following functionality: SupportsAuthentication Credential Repository and Processing Function (ARPF).This function stores the long-term security credentials used inauthentication for AKA. Stores Subscription information. NOTE 1: UDR(User data repository) could be present within the UDM. NOTE 2: Theinteraction between UDM and HSS is implementation specific. 6.2.8 AUSFThe AUSF supports the following functionality: Supports AuthenticationServer Function (AUSF) as specified by SA WG3. 6.2.9 N3IWF Thefunctionality of N3IWF in case of untrusted non-3GPP access includes thefollowing: Support of IPsec tunnel establishment with the UE: The N3IWFterminates the IKEv2/IPsec protocols with the UE over NWu and relaysover N2 the information needed to authenticate the UE and authorize itsaccess to the 5G core network. Termination of N2 and N3 interfaces to 5Gcore network for control-plane and user- plane respectively. Relayinguplink and downlink control-plane NAS (N1) signalling between the UE andAMF. Handling of N2 signalling from SMF (relayed by AMF) related to PDUsessions and QoS. Establishment of IPsec Security Association (IPsec SA)to support PDU Session traffic. Relaying uplink and downlink user-planepackets between the UE and UPF. This involves:De-capsulation/Encapsulation of packets for IPSec and N3 tunnellingEnforcing QoS corresponding to N3 packet marking, taking into accountQoS requirements associated to such marking received over N2 N3user-plane packet marking in the uplink. Local mobility anchor withinuntrusted non-3GPP access networks using MOBIKE. Supporting AMFselection.

Thus, based on Table 2 above, a UE 410 may utilize 3GPP access 412 toaccess AMF 420. For example, UE 410 may use an N1 interface for suchaccess.

The interface between 3GPP access 412 and AMF 420 may be an N2interface.

Alternatively, UE 410 may communicate with AMF 420 through UntrustedNon-3GPP Access 430. The interface between UE 410 and AMF 420 is an N1interface. Further, a Y1 interface may be used between UE 410 andUntrusted non-3GPP Access 430.

UE 410 may further communicate with N3IWF 440 through Untrusted Non-3GPPAccess 430 using an NWu interface. As provided in 3GPP TS 23.510, theNWu is a used between the UE and N3IWF for establishing secure tunnelsbetween the UE and N3IWF so that control-plane and user-plane trafficexchanged between the UE and the 5G Core Network is transferred securelyover untrusted non-3GPP access.

AMF 420 and N3IWF 440 may communicate using an N2 interface.

AMF 420 may further communicate with SMF 450 using an N11 interface.

3GPP Access 412 and N3IWF 440 may communicate with a UPF 460 using an N3interface. UPF 460 may then communicate with an external data network470 using an N6 interface.

SMF 450 and UPF 460 may further communicate using an N4 interface.

Emergency numbers via WLAN and policy using NAS indicator via 3GPP AN(Access Network)

Example definitions from 3GPP TS 23.167, “IP Multimedia Subsystem (IMS)emergency sessions”, v.14.3.0, March 2017, are provided in Table 3below.

TABLE 3 definitions from 3GPP TS 23.167 4.1 Architectural Principles Thesolution for emergency sessions in the IMS fulfils the emergencyprinciples and requirements of TS 22.101, TS 22.228 and the followingarchitectural requirements: 2a. Emergency numbers/types received viaWLAN are only used for detecting emergency calls in the same country, ifpermission from PLMN selected in 3GPP access was received (see TS 23.401and TS 23.060). J.2 UE specific behaviour Procedure for determining thelist of emergency numbers: In addition to the emergency numbers/typesstored either on the USIM or on the user equipment specified in TS22.101 clause 10.1.1, the UE shall use the stored Local EmergencyNumbers List received from the 3GPP network to detect that the numberdialled is an emergency number. If a UE has a SIM/USIM and has receiveda list of emergency numbers/types from the last registered PLMN viamobility management procedures as described in TS 24.301 and TS 24.008when connected to the PLMN using UTRAN or E-UTRAN radio access network,the UE shall use this list to determine if the dialled digits correspondto an emergency call as long as the UE has determined that the list isvalid (i.e. UE has determined that it is in the same country when thelist of emergency numbers was received from PLMN). The UE may alsodetermine that the dialled digits/types correspond to an emergency callbased on the list of emergency numbers retrieved by one of the followingmeans: NOTE: How the UE uses two lists (a list of emergencynumbers/types received via mobility management procedures and a list ofemergency numbers retrieved via the WLAN) is a stage 3 decision. a) viaAccess Network Query Protocol (ANQP) procedures defined in IEEE Std802.11-2012 from the associated WLAN AP upon completing authenticationwith the trusted WLAN, with management frame protection enabled. b) viaa previous query to a DNS only when that DNS is in the same country asthe UE and is an internal DNS server in the 3GPP network whose addressis acquired from the ePDG; or c) via IKEv2 procedures from ePDG. Thelist of downloaded emergency numbers shall be deleted at country change.

Further, example definitions from 3GPP TS 23.060, “General Packet RadioService (GPRS); Service description; Stage 2”, v.14.3.0, March 2017, and3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses”,v.14.3.0, March 2017, are provided in Table 4 below.

TABLE 4 definitions from 3GPP TS 23.060 and 23.402 For emergencyservices other than eCall, a UE determines from a NAS indicator thatadditional emergency numbers/types received via WLAN may be used fordetecting emergency calls.

Emergency Numbers Via 3GPP AN (Access Network)

When connected to a PLMN using GERAN, UTRAN or E-UTRAN radio accessnetwork a list of emergency numbers/types can be received at the UEduring mobility management procedures as described in TS 24.301 and TS24.008. Mobility management procedures in these accesses include attachprocedures, location area update procedures, tracking area updateprocedures, routing area update procedures. During these procedures alist of emergency numbers/types for the PLMN the UE is performing theprocedures with, can be received.

For the above aspects and predicates, UEs need to know emergency numbersand types or categories (e.g. fire, ambulance, police, mountain rescueetc.) for which “UE detected emergency calls are” supported by a PLMNvia a Trusted WLAN or untrusted WLAN. In the same country, differentPLMNs may support different “UE detected emergency calls”.

For example, PLMN A configures the UE attaching to its network to detectdial digits (e.g. 110) as an emergency call. This UE, when detectingdialled digits 110, will perform “UE detected emergency call”procedures. The EMERGENCY SETUP (in case of selecting the CS (circuitswitched) domain) will not include the dialled digits, rather it willinclude a derived category encoded in 5 bits. E.g. category “fire”.

PLMN B (in the same country) has not configured its network to routecalls categorized as fire to a PSAP capable of handling fire-relatedemergencies. PLMN B's network relies on receiving the dialled digits todo so. PLMN B will therefore not configure UEs attached to its networkto detect 110 as an emergency number.

A UE connected to different PLMNs via 3GPP access and WLAN access may beconfigured by both PLMN's with emergency call numbers. When the UE hasbeen configured with PLMN A's emergency numbers and types or categoriesvia WLAN, and the UE uses these to initiate a “UE detected emergencycall” via e.g. 3GPP access where the serving network is PLMN B, thenPLMN B may receive a “UE detected emergency call” for a type/categoryfor which it hasn't configured its network. Instead, PLMN B would haveexpected to receive a normal call (a normal call is a non-emergencycall. The message initiating the call includes the dialled digits). Thenormal call would include dialed digits. The network would then parsethe dialed digits and possibly route the call to the correct PSAP basedon the dialed digits.

Therefore, in accordance with the embodiments of the present disclosure,emergency numbers may be configured in various ways.

WLAN ANQP

In accordance with one embodiment, at least one list of emergencynumbers and their types or categories may be included in the ANQPresponse; e.g. one for each PLMN or service provider. Reference is nowmade to FIG. 5 , which shows a general procedure for receipt ofemergency information.

In FIG. 5 , A UE 510 may communicate with a network node 512, which maycommunicate with a network node 514. Network node 512 may, for example,be an access point. Network node 514 may, for example, be anadvertisement server for ANQP.

In the embodiment of FIG. 5 , UE 510 sends a message 520 to Network Node512 and Network Node 512 receives the message 520. Message 520 may be anANQP request and may contain Additional UE Provided Information.

In the embodiment of FIG. 5 , the Credit Control (CC)-request andCC-answer may be DIAMETER or (equivalent) RADIUS messages. They couldalso be messages part of another protocol.

Upon receiving Message 520, Network Node 512 may send Message 522 toNetwork Node 514. Message 522 may contain Additional UE ProvidedInformation e.g. if received in Message 520. In one embodiment message522 may be a CC-Request.

In some embodiments, the functionality of Network Node 514 may beco-located with Network Node 512, so that Message 522 and Message 524become internal messages within Network Node 512.

In the embodiment of FIG. 5 , upon receiving Message 522, Network Node514 sends Message 524 to Network Node 512. Message 524 may contain oneor both of Routing Data and/or an error message. In one embodimentmessage 524 may be a CC-Answer.

Upon receiving Message 524, Network Node 512 sends Message 526 to UE510. Message 526 may contain one or both of Routing Data and/or an errormessage, for example depending on what was received in Message 524.Message 526 may be considered an ANQP response in one embodiment.

Thus, in accordance with the above, UE 510:

-   -   sends a ANQP request message indication; at least one of        “Emergency Call Number”    -   ANQP-element or “3GPP Cellular Network” ANQP-element receives an        ANQP response message indication; at least one of “Emergency        Call Number” ANQP-element or “3GPP Cellular Network”        ANQP-element, the ANQP response message further including at        least one list of emergency numbers, the list of emergency        numbers being associated with at least one of a service provider        identifier or a country code.

Further, in accordance with the above, Network Node 512:

-   -   receives a ANQP request message indication; including at least        one of “Emergency Call Number” ANQP-element or “3GPP Cellular        Network” ANQP-element    -   sends an ANQP response message indication; including at least        one of “Emergency Call Number” ANQP-element or “3GPP Cellular        Network” ANQP-element, the ANQP response message further        including at least one list of emergency numbers, the list of        emergency numbers being associated with at least one of a        service provider identifier or a country code.

Further, UE 510 or network node 512, may additionally provide or beprovided other information.

-   -   Optionally, the ANQP response message indicates one or more        emergency categories or types per emergency number.    -   Optionally, the service provider identifier comprises a PLMN        code    -   Optionally, the service provider identifier comprises a NAI        realm    -   Optionally, the NAI realm comprises a PLMN code    -   Optionally, the PLMN code comprises a MCC and a MNC    -   Optionally, the country identifier comprises one or more MCC        codes, or one or more IEEE 802.11d country codes or one or more        two letter country codes or one or more 3 letter country codes.

In general, the “Emergency Call Number” ANQP-element enables an AP orANQP server to respond with, for example, UTF-8 strings of characters.To include PLMN specific lists of emergency numbers, types/categories inthis string, the string would indicate the PLMN to which this listapplies. A high-level example encoding is provided in Table 5 below:

TABLE 5 Example Encoding of Emergency Call Number [One or more<MNC,MCC>: [one or more <emergency digits>, [one or more <emergencytype>]>]]

In some embodiments, optimizations of data may be provided. For example,the data to be provided via ANQP could be reduced in some cases. Forexample, where all PLMNs in the same country (i.e. share one or moreMCCs) support the same “UE detectable emergency calls”, the exampleencoding could be as follows in Table 6.

TABLE 6 Example Optimized Encoding of Emergency Call Number One or more<MCCs>: [one or more <emergency digits>, [one or more <emergencytype>]>]]

In some cases, some countries have reserved more than one mobile countrycode (MCC). Further, in some cases a mixture of the encoding of Tables 5and 6 above could be used.

ABNF

In a further embodiment Augmented Backus-Naur form may be used.

In general, the Emergency Call Number field is a variable-length UTF-8(see RFC 3629) formatted field. The purpose of this field is to encodeemergency number(s) (and type(s) of category(ies)) for use within thecountry where the field is received, for example per PLMN. Thissubclause describes the formatting of the Emergency Call Number fieldused in the Emergency Call Number ANQP-element specified in IEEE802.11-2016.

The formatting, in general is described as follows. For the purposes ofaiding the detection of an emergency call number and assigning theemergency type, the Emergency Call Number field can contain zero or moremobile network codes (MNC) codes, one or more MCC codes, an emergencycall number and zero or more emergency call types (or categories). Theemergency call number and zero or more emergency call types are encodedas namespace specific strings for the namespace identifier equal to 3gpp(see IETF RFC 5279). This specification further defines a namespaceidentifier, e.g. a namespace identifier equal to sos-anqp andparameters.

With regards to ABNF for the Uniform Resource Name (URN)urn:3gpp:sos-anqp namespace and its parameters, Table 7 below containsthe ABNF (IETF RFC 2234) for the urn:3gpp:sos-anqp namespace and itsparameters. For example the URN“urn:3gpp:sos-anqp:mcc404:mcc405:101:sos.fire” can be expressed usingthe conventions coded in Table 7.

TABLE 7 Syntax of urn:3gpp:sos-anqp emergency-information =“urn:3gpp:sos-anqp:” mcc (“:” mnc) *(“:” mcc (“:” mnc)) *(“:”emergency-number *(“:” label)) emergency-information =/“urn:3gpp:sos-anqp:noLocalEmergencyNumbers” emergency-information =/“urn:3gpp:sos-anqp:keepLocalEmergencyNumbers” emergency-information =/“urn:3gpp:sos-anqp” emergency-number  = DIGIT*DIGIT  ; at least oneDIGIT mcc = DIGIT DIGIT (DIGIT)  ; exactly 2 or 3 digits mnc = DIGITDIGIT (DIGIT)  ; exactly 2 or 3 digits label = “sos” *(“.” sub-label)sub-label = let-dig [ *let-dig-hyp let-dig ] let-dig-hyp = let-dig / “−”let-dig = ALPHA/DIGIT ALPHA  = % x41-5A / % x61-7A   ; A-Z / a-z DIGIT =% x30-% x39; ; 0-9

While the syntax of Table 7 allows for many different sub-labelsfollowing “sos”, when originating an emergency IMS session (see TS24.229) based on detecting a match with dialed digits, the SIP INVITEmay only contain one of the following service URNs “urn: service: sos”,“urn: service: sos. ambulance”, “urn: service: sos.police”, “urn:service: sos. fire”, “urn: service: sos.marine”, “urn: service:sos.mountain”

Table 7 uses a URN namespace, e.g. “urn:3gpp:sos-anqp:” to identify the3GPP encoding. Other SDOs can use their own encoding.

A 3GPP UE can receive a list with emergency numbers or an empty list. Anempty list is e.g. indicated as “urn:3gpp:sos-anqp” or“urn:3gpp:sos-anqp:noLocalEmergencyNumbers” or“urn:3gpp:sos-anqp:mccXX(X)”. The empty list causes a UE to overwrite apreviously received list with local emergency numbers with an emptylist. The XX(X) (in the previous sentence's example“urn:3gpp:sos-anqp:mccXX(X)”) indicates the 2 (or 3) digits of the MCC.

When the UE receives “keepLocalEmergencyNumbers” included within thisANQP-element field, or when the ANQP-element field does not include aURN that starts with “urn:3gpp:sos-anqp” or when the UE does notrecognize the encoding (e.g. because the ABNF parser fails to parse thestring) or when the UE doesn't receive the ANQP-element field, the UEmay keep the numbers it had, in case the UE has previously receivedlist(s) with local emergency numbers.

When a 3GPP UE receives a list with emergency numbers, e.g.urn:3gpp:sos-anqp:mcc404:mcc405:101:sos.fire, the UE knows that in thecountry identified by two MCCs (i.e. codes 404 or 405 represent India)the number that summons the fire department to an emergency is “101”. Onthe other hand, for exampleurn:3gpp:sos-anqp:mccABC:mncXYZ:18:sos.fire:sos.ambulance indicates thatthe operator XYZ in country ABC has configured its network to recognizeemergency calls typed fire or categorized fire and ambulance. In thisnetwork, the UE can detect dialled digits 18 as an emergency number. TheUE can then initiate emergency call procedures as opposed to normal(non-emergency) call procedures.

3GPP Cellular Network ANQP-Element

In a further embodiment, the “3GPP Cellular Network” ANQP-elementenables an AP or ANQP server to respond with an information elementdefined by 3GPP in TS 24.302.

TS 24.302 describes the structure and contents of the generic containerused as the payload in the 3GPP Cellular Network ANQP-element specifiedin IEEE 802.11-2016.

The generic container for the ANQP payload can convey a PLMN List or aPLMN List with S2a connectivity. The PLMN List information element isused by the network to indicate the PLMNs that can be selected from theWLAN. The PLMN List with S2a connectivity information element is used bythe WLAN to indicate the PLMNs to which the WLAN provides S2aconnectivity.

The “3GPP Cellular Network” ANQP-element can be enhanced to convey perPLMN emergency number/type lists or per MCC emergency number/type lists.

For example, Table 8 represents changes to the definition of the genericcontainer within 3GPP TS 24.302, Annex H, as shown in bold and underlinein the table.

TABLE 8 Changes to 3GPP TS 24.302 shown in bold and underlining H.2.4.1Information Element Identity (IEI) Indicates the information elementidentity. The following values for IEI are defined in this version ofthe specification: 00000000 PLMN List 00000001 PLMN List with S2aconnectivity 00000002 Emergency numbers list 0000000 3 To 11111111Reserved H.2.4.X   Emergency   numbers   list   IE The   Emergency  numbers   list   information element   is   used   by   the   WLAN   toindicate   the   emergency   numbers   available via   a   PLMN.   The  format   of   the PLMN   List   information   element   coded according  to   3GPP   TS   24.007 subclause   11.2.2.1   is   shown   in   Table  H.2.4.X-1. NOTE:   the   Length   of   Emergency numbers   container  contents   field   below may   have   to   be   2   octets   long   as  opposedto the   1   octet   reserved   now   (in   H.2.4.X-1). Emergency  numbers   IEI octet   1 Length   of   Emergency   numbers   containeroctet   2 contents Number   of   Emergency   number   containers octet  3 Emergency   number   container,   container   1 octet   4 octet   5Emergency   number   container, octet   X Table   H.2.4.X-1:   Emergency  numbers   information   element The   “Number   of   Emergency  number containers”   (octet   3)   contains   the number   of  Emergency   number   container information   items   in   the   list.  Bit   7 of   octet   3   is   the   most   significant   bit   and   bit  0   of octet   3   the   least   significant   bit. The   Emergency  number   container   is coded   as   shown   in   below. NOTE:   the  Length   of   Emergency number   container   contents   field   below  may   have   to   be   2 octets   long   as   opposed   to   the   1  octet   reserved   now   (in Table   H.2.4.X-2). 8 7 6 5 4 3 2 1 Length  of   Emergency   number   container   contents octet   1 Number   of  PLMN   codes octet   2 MCC   digit2 MCC   digit   1 octet   3 MNC  digit3   (Note   0) MCC   digit   3 octet   4 MNC   digit2   (Note   0)MNC   digit   1   Note   0) octet   5 MCC   digit   2 MCC   digit   1octet   6 MNC   digit   3   (Note   0) MCC   digit   3 octet   7 MNC  digit   2   (Note   0) MNC   digit   1   (Note   0) octet   8 . . . . .. Length   of   1st   Emergency   Number   information octet   i (Note  1) Spare Emergency octet 0 0 0 Service   Category i+1 Value Number  digit   2 Number   digit   1 octet i+2 (Note 2) Number   digit   4Number   digit   3 octet i+3* : : : (Note   3) octet j−1* Length   of  2nd   Emergency   Number   information octet   j* (Note   1) SpareEmergency octet 0 0 0 Service   Category j+1* Value Number   digit   2Number   digit   1 octet j+2* (Note 2) Number   digit   4 Number   digit  3 octet j+3* : : : (Note   3) : octet j+k* . . . . . . Length   of  xth   Emergency   Number   information octet (Note   1) n* SpareEmergency octet 0 0 0 Service   Category n+1* Value Number   digit   2Numberdigit   1 octet n+2* (Note 2) Number   digit   4 Numberdigit   3octet n+3* : : : (Note   3) : octet n+m* NOTE   0: If   the   PLMN  code   only   includes   an   MCC   code,   the   four   bits   of   the  res- pective   digit   shall   be   coded   as   “1111”. NOTE   1: The  length   contains   the   number   of   octets   used   to   encode  the   Emergency Service   Category   Value   and   the   Number  digits. NOTE   2: The   number   digit(s)   in   octet   5   precedes  the   digit(s)   in   octet   6   etc.   The   num- ber   digit,   which  would   be   entered   first,   islocated   in   octet   5,   bits   1  to   4.   The contents   of   the   number   digits   are   coded   as  shown   in   table   10.5.118/3GPP TS24.008. NOTE   3: If   the  emergency   number   contains   an   odd   number   of   digits,   bits  5   to   8   of the   last   octet   of   the   respective   emergency  number   shall   be   filled   with   an end   mark   coded   as  “1111”. Table   H.2.4.X-2   Emergency   Number   List   information  element Table   H.2.4.X-1:   Emergency   Number   List   information  element Emergency   Service   Category   Value   (octet   4,   j+1,  n+1,   etc.;   bit   1   to   5) Bits   1   to   5   are   coded   as  bits   1   to   5   of   octet   3   of   the   Service   Categoryinformation   element   as   specified   in   subclause   10.5.4.33/3  GPP   TS   24.008.

When the UE receives a 3GPP Cellular Network ANQP Element with contentlength set to 0 or 3GPP Cellular Network ANQP-element without the IEIfield set to “00000002” or “Emergency numbers list” (see H.2.4.1), thenthe UE may keep the numbers it had, in case the UE has previouslyreceived a list with local emergency numbers.

In the embodiments described herein, the “Emergency numbers list” mayalso be known as “Additional emergency numbers list”.

EmergencyNumberList ANQP-Element

In a further embodiment, an alternative is to enhance for example theWi-Fi Alliance Hotspot 2.0 specifications or IEEE 802.11-2016 forencoding and providing the information. Similar encoding can be used toenhance the IEEE 802.11-2016 specification.

In this alternative, a new ANQP-element is defined. The new ANQP-elementencodes the information is a binary version, without further overloadingthe 3GPP Cellular Network ANQP Element.

Referring to Table 9 below, the following bold and underlined textrepresents example changes to the Wi-Fi Alliance Hotspot 2.0 (Release 2)Technical Specification Version 1.2.5

TABLE 5 HS2.0 ANQP-element Subtype Definition Subtype DescriptionElement Name Value (subclause) Extensible Reserved 0 n/a Emergency- 124.X Number   List indicator   list Reserved 13-255 n/a

TABLE 6 HS2.0 ANQP-element Usage ANQP- ANQP- ANQP- Element elementMobile element Name (subclause) type AP Device Emergency- 4.X S T RNumber   List indicator   list Symbols Q element is an ANQP Query Selement is an ANQP Response T ANQP-element may be transmitted by MACentity R ANQP-element may be received by MAC entity Subclause   4.X.  EmergencyNumberList indicator   list   element The   EmergencyNumberListindicator   list   element   provides   information   aboutEmergencyNumberList   indicator   information available   within   the  IEEE   802.11   AN. The   EmergencyNumberList   selection   indicator  element may   include   one   of   more   of   the   following:  • EmergencyNumberList  • The format of the  EmergencyNumberList  indicator   list   element   is provided in Table 4.X.1EmergencyNumberList indicators Octets: variable   Table   4.X.1 - EmergencyNumberList      indicator   list   element   format The  EmergencyNumberList   Indicators   field   contains   one   or   more  variable   length EmergencyNumberList   Indicator   fields. The   format  of   each   EmergencyNumberList   indicator   field   is   provided  in   Table   4.X.2.

TABLE 9 Changes to Wi-Fi Alliance Hotspot 2.0 shown in bold andunderlining Selection   Content Selection   Indicators Octets: 1variable Table 4.X.2 - EmergencyNumberList selection indicator fieldformat The   Selection   Content   is   a   1   octet   subfield whose  value   indicates   what   additional   information can   be   found  in   each   Selection   Indicator   sub-field: Meaning bit PLMNID 0Short   code   (digits) 1 Short   code 2 (alphanumeric) Short   Code  (NAI) 3 Short   Code   (3gpp 4 container) Reserved 5-15 The   Selection  Indicators   field   contains   one or   more   Selection   Indicator  1-octet subfields,   each   of   which   corresponds to   a   set  bit   within   the   Selection   Content subfield.   For   example  ifbits   1   and   3 are   equal   to   1   within   the   Selection  Content field,   then   the   Selection   Indicators   field contains  the   Selection   Indicator   #2   and Selection   Indicator   #4  subfields. The   format   of   the   Selection   Indicator subfields  is   defined   as   follows. Selection   Indicator   #2   is   a  variable   length octet   subfield.   It   contains   a   Shortcode.Meaning Octet Length 1 Shortcode variable The  Shortcodefieldisdefinedasbelow Spare EmergencyService octet   i+1 0   0  0 Category   Value Number   digit2 Number octet   i+2 digit   1 (Note  2) Number   digit4 Number   digit   3 octeti+3* : : : (Note3) octet  j−1* Selection   indicator   ”Short   code (alphanumeric)”   is   a  variable   length   octet subfield.   It   contains   a   1-octet  length   field   and   aSIP   URI. The   format   of   the   Selection  Indicator “Short   Code   (NAI)”   is   same   as   the   frame defined  in   IEEE   802.11-2016   [ 12 ]   subsection   9.4.5.10 (NAI  Realm),   except   the   Info   ID   field. The   format   of   the  Selection   Indicator   “Short   Code (3gpp   container)”is   same   as  the   frame   defined   in   IEEE   802.11-2016   [ 12 ]   subsection  9.4.5.11 (3GPP   Cellular   Network),   except   the   Info   ID  field.

EAP Procedure

In a further embodiment, an EAP procedure is provided. In accordancewith the embodiment of FIG. 6 described below, a UE 610:

-   -   sends an authentication message 620 to the AAA server 616        containing either one to many identities.    -   Receives an authentication message 630 from the AAA server 616        containing a parameter “EmergencyNumberList selection indicator        supported”        -   This parameter indicates that the AAA server 616 can send            “EmergencyNumberList”    -   Sends an authentication response message 632 to the AAA server        616 containing a request for an EmergencyNumberList.    -   Receives an authentication message 640 from the AAA server 616        containing the “EmergencyNumberList”.

Further, a AAA 616:

-   -   Receives a message 620 from the UE 610 with at least one        identity    -   Sends a message 630 to the UE 610 containing a parameter        “EmergencyNumberList supported”        -   This parameter indicates that the AAA server can send            “EmergencyNumberList” in a later authentication message.    -   receives an authentication message 632 containing an indication        that an EmergencyNumberList is required    -   Sends an authentication message 640 to the UE 610 containing a        parameter “EmergencyNumberList”.

In addition to the messages described above, AAA 616, on receivingmessage 620 provides the Public User Identity to HSS 618 in message 622.AAA 616 then receives Challenge Vectors from HSS 618 in message 624.These Challenge Vectors are then used as part of message 630.

Further, on receiving message 632, AAA 616 then sends an authenticationresponse 634 to HSS 618 and receives an acknowledgement 636 back fromHSS 618. This acknowledgement is then used for message 640.

The above provides for a first authentication mechanism. Subsequently,an IMS registration may occur, as for example as shown by arrow 650between UE 610 and X-CSCF 614, and by arrow 652 between X-CSCF 614 andHSS 618 in the embodiment of FIG. 6 . As used in the present disclosure,“X-CSCF” represents the P-CSCF or the Serving-Call Session ControlFunction (S-CSCF).

The changes to support FIG. 6 are described below. In particular, FIG. 6is described by the text and tables below which are potentialmodifications to 3GPP TS 24.302. However, the embodiment of FIG. 6provide logical functions that may be combined together. For example,ePDG 612 has an AAA function in it to terminate or proxy EAP messages.

Referring to Table 10 below, the text in bold and underline shows oneexample potential modification to a specification, section numbers andreferences are those in that specification.

TABLE 10 Proposed changes to 3GPP TS 24.302 6.2.5   EmergencyNumberList  configuration If   the   UE   performs   3GPP-based   accessauthentication,   the   3GPP   AAA   server   may send   a   list   of  emergency   numbers   from   the non-3GPPaccessnetworktotheUEduringtheEAP-AKAorEAP-AKA'based accessauthentication(i.e.EAP-AKA,EAP-AKA').Theindicatorissentusinga ATEmergencyNumberListRESP,byextendingtheEAP-AKA(andEAP-AKA') protocolasspecifiedinsubclause8.2ofIETFRFC4187.Thisattributeisprovidedin EAP-Request/AKA-ChallengeorEAP-Request/AKA'-Challengemessagepayload respectively.Thedetailedcodingofthisattributeisdescribedinsubclause8.2.X.1.6.XAEmergencyNumberListconfiguration(Xis4or5) 6.XA.1UEProcedures 3-4)If:  a)   the   UE   supports   the   “Configuration   request”;   b)   the  EAP-Request/AKA'-Challenge   message   includes   the    AT  EmergencyNumberList   REQUEST      SUPPORTED   attribute   as  described    in   subclause   8.2.X.1   wherein   the   message   field  as      described   in   subclause   8.1.4.1:    1)   contains   the  message   type   field   indicating     EmergencyNumberList   REQUEST  SUPPORTED;   and    2)   contains   the   type   field   including     the   EmergencyNumberList   Request     Supported   field   item   as  described   in   subclause   8.2.X.1       indicating  EmergencyNumberList   Supported;   and   c)   the   UE   requests  usage   of   the   “   EmergencyNumberList   ”; 5-6)   then   the   UE:  a)   shall   include   the   AT   EmergencyNumberList     REQUEST  attribute   according    to   subclause   8.2.X.2   in   the  EAP-Response/    AKA'-Challenge   message.   In   the    message   field  according   to   subclause   8.1.4.1   of   the   AT   EmergencyNumberList   REQUEST   attribute,   the   UE   shall:    1)  set   the   message   type   field   to      EmergencyNumberList  REQUEST;   and    2)   contains   the   type   field   including     the   EmergencyNumberList   Request   field     item   as   described  in   subclause   8.2.X.2   indicating       EmergencyNumberList  requested;   and 7-8)   Upon   receiving   the   EAP-Request/AKA'-Notification   message   including   the AT   EmergencyNumberList  RESP   attribute   as   described   in   subclause   8.2.X.3 where   the  message   field   as   described   in   subclause   8.1.4.1:  - contains   the   message   type   field      indicating  EmergencyNumberList   RESP;    and   - contains   the   field  EmergencyNumberList   Encoded; the   UE:   - stores   the  EmergencyNumberList      received   to   be   used   to   determine   if  a    dialled   call   is   an   emergency   call. If   this   message  is   received   in   EAP-AKA'   signalling   used   in   tunnel  set-up   to   an ePDG,   the   received   EmergencyNumberList   shall  be   considered   an   alternative EmergencyNumberList   to   use   by  the   UE. 6.XA.2   AAA   Procedures The   3GPP   AAA   server   may  support   EmergencyNumberList   configuration. 3-4)   If   the   network  supports   EmergencyNumberList   configuration,   the   3GPP   AAAserver   shall   include   a)   in   the   EAP-Request/AKA'-Challenge  message,   the    AT   EmergencyNumberList   REQUEST      SUPPORTED  attribute   as   described    in   subclause   8.2.X.1,   wherein   the  message   field   as      described   in   subclause   8.1.4.1:    1)  contains   the   message   type   field   indicating    EmergencyNumberList   REQUEST   SUPPORTED;   and    2)   contains   the  type   field   including      the   EmergencyNumberList   Request    Supported   field   item   as   described   in   subclause   8.2.X.1      indicating   EmergencyNumberList   Supported;   and 5-6)   If   the  3GPP   AAA   server   supports   EmergencyNumberList   configuration;  and the   AAA   server   receives   the   AT   EmergencyNumberList  REQUEST   attribute according   to   subclause   8.2.X.2   in   the  EAP-Response/AKA'-Challenge   message and   In   the   message   field  according   to   subclause   8.1.4.1   of   the AT   EmergencyNumberList  REQUEST   attribute    1)   the   message   type   field   is   set  to      EmergencyNumberList   REQUEST;   and    2)   contains   the  type   field   including   the     “EmergencyNumberList   REQUEST      SUPPORTED”   value   (see   Table   8.1.4.1-2)       as   described   in  subclause   8.2.X.2   indicating     EmergencyNumberList   requested;then   the   AAA   server   optionally   contacts   an   external  database   e.g.   HSS,   PCRF   to obtain   the   EmergencyNumberList  to   be   used   and   provides   those   EmergencyNumberList   in   the  EAP-RSP/AKA'-identity   message. 7-8)   The   AAA   sends   the  EAP-Request/ AKA'-Notification   message   including   the AT  EmergencyNumberList   RESP   attribute   as   described   in   subclause  8.2.X.3 where   the   message   field   as   described   in  subclause   8.1.4.1:   - contains   the   message   type   field     indicating   EmergencyNumberList   RESP;    and   - contains   the  field   EmergencyNumberList   Encoded   as      described   in  subclause   8.2.X.3.2; 8   PDUs   and   parameters   specific   to   the  present   document   8.1   3GPP   specific   coding   information    defined   within   present   document 8.1.4   PDUs   for   TWAN  connection   modes 8.1.4.1   Message The   message   is   coded  according   to   table   8.1.4.1-2. Table   8.1.4.1-2:   Message   typeThe   value   is   coded   as   follows. 7   6   5   4   3   2   1   0 0  0   0   0   0   0   0   1 CONNECTION   CAPABILITY 0   0   0   0   0  0   1   0 SCM   REQUEST 0   0   0   0   0   0   1   1 SCM   RESPONSE 0  0   0   0   0   1   0   0 MCM   REQUEST 0   0   0   0   0   1   0   1MCM   RESPONSE 0   0   0   0   0   1   1   1 EmergencyNumberList  REQUEST   SUPPORTED 0   0   0   0   1   0   0   0 EmergencyNumberList  REQUEST 8.2.XIdentity   attributes 8.2.X.1   AT   EmergencyNumberList  Request   Supported   attribute 7   6   5   4   3   2   1   0 Attribute  Type   =   AT   EmergencyNumberList octet   1 request   supportedoctet   2 Length   =   1 octet   3 Value octet   4 Table   8.2.X.1-1:  AT   EmergencyNumberList   Request   Supported   attribute Table  8.2.X.1-1::   AT   EmergencyNumberList   Request   Supported Octet   1  (in   Table   8.2.X.1-1)   indicates   the   type   of   attribute   asAT   EmergencyNumberList   Request   Supported. Octet   2   (in   Table  8.2.X.1-1)   is   the   length   of   this   attribute   which   shall  be set   to   1   as   per   IETF   RFC   4187 Octets   3   (in  Table   8.2.X.1-1)   and   4   (in   Table   8.2.X.1-1)   are   the  value   of   the   attribute.   Octet   3   (in   Table   8.2.X.1-1)  is   reserved   and   shall   be   coded as   zero.   Octet   4   (in  Table   8.2.X.1-1)   shall   be   set   as   follows.   All   other  values   are   reserved. 7   6   5   4   3   2   1   0EmergencyNumberList   Request Supported   field 0   0   0   0   0   0  0   1 EmergencyNumberList   Request Supported 0   0   0   0   0   0   1  0 EmergencyNumberList   Request   not   supported 1   1   1   1   1  1   1   1 Reserved 8.2.X.2   AT   EmergencyNumberList   Request  attribute 7   6   5   4   3   2   1   0 Attribute   Type   = octet   1AT   EmergencyNumberList   Request octet   2 Length   =   1 octet   3Value octet   4 Table   8.2.X.2-1:   AT   EmergencyNumberList   Request  attribute Table   8.2.X.2-1::   AT   EmergencyNumberList   Request  attribute Octet   1   (in   Table   8.2.X.2-1)   indicates   the   type  of   attribute   as AT   EmergencyNumberList   Request   with   a  value   of   1XX. Octet   2   (in   Table   8.2.X.2-1)   is   the  length   of   this   attribute   which set   to   1   as   per   IETF  RFC   4187   [ 33 ] Octet   3   (in   Table   8.2.X.2-1)   and   4   (in  Table   8.2.X.2-1)   is   the   value   of   the attribute.   Octet  3   (in   Table   8.2.X.2-1)   is   reserved   and   shall   be   coded  as zero.   Octet   4   (in   Table   8.2.X.2-1)   shall   be   set  as   follows.   All   other   values   are   reserved. 7   6   5   4   3  2   1   0 EmergencyNumberList   requested   field 0   0   0   0   0  0   0   1 EmergencyNumberList   requested 0   0   0   0   0   0   1   0Reserved   to 1   1   1   1   1   1   1   1 Reserved 8.2.X.3   AT  EmergencyNumberList   RESP   attribute 8.2.X.3.1   General 7   6   5   4  3   2   1   0 Attribute   Type   = octet   1 AT   EmergencyNumberList  RESP octet   2 Length   =   1 octet   3 Value octet   Z Table  8.2.X.3-1:   AT   EmergencyNumberList   RESP   attribute 8.2.x.3.2  EmergencyNumberList   encoded There   may   be   multiple  EmergencyNumberLists   encoded   in   the AT   EmergencyNumberList  RESP   attribute. 7   6   5   4   3   2   1   0 EmergencyNumberList  encoded octet   1 Length   =   1 octet   2 EPDG octet   3 octet   ZTable   8.2.X.3-1:   AT   EmergencyNumberList   RESP   attribute   ValueTable   8.2.X.3-1::   AT   EmergencyNumberList   RESP   attribute  Value Octet   1   (in   Table   8.2.X.3-1)   indicates   the   identity  that   is   encoded.   . Octet   1   (in   Table   8.2.X.3-1)   shall  be   set   as   follows.   All   other   values   are   reserved. 7  6   5   4   3   2   1   0 EmergencyNumberList   Encoded   field 0   0  0   0   0   0   0   1 EmergencyNumberList   UTF   8   Encoded 0   0   0  0   0   0   1   0 EmergencyNumberList   as   define   in Section  H.2.4.X   (above) 0   0   0   0   0   0   1   1 Reserved   to 1   1   1  1   1   1   1   1 Reserved 8.2.x.3.3   EmergencyNumberList The  EmergencyNumberList   field   is   an   octet   string   encoded  according   to   UTF-8 encoding   rules   containing   an   SIP   or  Tel   URI.

As an alternative, instead of using AT EmergencyNumberList REQUEST anInternet Key Exchange Protocol Version 2 (IKEv2) CFG_REQUEST may be usedto request the EmergencyNumberList.

As an alternative, instead of using AT EmergencyNumberList RESPattribute, a CFG_REPLY may be used that contains theEmergencyNumberList.

DHCP

In a further embodiment, DHCP may enhanced so that an“EmergencyNumberList” can be returned to the UE when the UE performsDHCP negotiation after attaching to the WLAN and attempt to negotiatewith a DHCP server to gain certain information. For example, theinformation may be IP layer information such as IP address to use, DNSserver IP addresses, among other options.

A UE may utilise DHCP to discover the details of one or moreEmergencyNumberList(s). A UE may perform such a DHCPoperation/transaction regardless of whether DHCP is being used to alsoobtain an IP address e.g. consider the case where a UE learns an IPaddress via a PCO, or the case where a UE learns an IP address throughstateless address autoconfiguration.

DHCP may convey one or a combination of the following different types ofparameters relating to the EmergencyNumberList:

-   -   Indication of one of the following:        -   A UE must attempt to use only an EmergencyNumberList in the            RPLMN of the WLAN        -   A UE must attempt to use only an EmergencyNumberList in the            RPLMN of the 3GPP access

A UE may, but need not, indicate itsability/intention/capability/support of an EmergencyNumberList in theRPLMN of the WLAN connection/selection in order to receive anEmergencyNumberList in the RPLMN of the WLAN related options/parametersfrom a DHCP server.

In the example of Table 11 below, DHCPv4 and DHCPv6 options are definedfor conveying ePDG IPv4 and IPv6 addresses, where XXX and YYY indicatereserved numerical values that each uniquely identify the new DHCPoption. Similar encoding could be assumed for any of the above listedparameters relating to EmergencyNumberList.

TABLE 11 Proposed modifications to RFC 21322.EmergencyNumberListOptionforDHCPv4   This   section   describes   an    EmergencyNumberList   option   for   DHCPv4.     The   option   layout  is   depicted   below:                 0 1 2 3 4 5 6 7 8 9 0 1 2                 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1          +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+     |           Option Code | Length                 |   +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+−    +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+   |              EmergencyNumberList                 |    +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+−    +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+   .                                                                   .   +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−    −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+  Option   Code    EmergencyNumberList   (XXX)   Length    Length   (in  bytes)   of   the   option      excluding   the   ‘Option   Code’  and    the   ‘Length’   fields;   ‘Length’   field      is   set   to  4N,   where   N   is   the   number   of      IPv4   addresses   carried  in   the   option   EmergencyNumberList as   defined   in   Section  H.2.4.X   (in   tables   above) 3.   EmergencyNumberList   Option   for  DHCPv6   This   section   describes   a   shortcode     option   for  DHCPv6.   All   values   in   the   option     are   represented   in  network   byte   order.   The   option   layout   is   depicted   below:    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+−    +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+   |       Option Code | Length                    |   +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+−    +−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+−+   |                EmergencyNumberList                    |     .                                                                     .    +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−    −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+   Option   Code   EmergencyNumberList   (YYY)   Length    Length   (in   bytes)   of   the  option      excluding   the   ‘Option   Code’   and    the   ‘Length’  fields;   ‘Length’      field   is   set   to   16N,   where   N   is  the    number   of   IPv6   addresses   carried   in   the   option  EmergencyNumberList as   defined   in   Section   H.2.4.X   (in   tables  above. 4.1.   Usage   of   Shortcode   Options   for   DHCPv4   The  requesting   and   sending   of   the     proposed   DHCPv4   options  follow   the   rules   for   DHCP   options   in   [ RFC2131 ] . 4.1.1.  Mobile   Node   Behavior   The   mobile   node   MAY   request     an  EmergencyNumberList   either   during   initial   association   with  a     network   or   when   the   mobile   node   determines   that   it  needs   an     EmergencyNumberList.   It   MAY   also   request   an  EmergencyNumberList   when   the   network   information   is   outdated  or   the     mobile   node   does   not   have   anyEmergencyNumberList   information.   In   order   to   request   an    EmergencyNumberList,   the   mobile   node   (DHCP   client)   MUST  include   an     EmergencyNumberList   IPv4   Address   Option   in the  Parameter   Request   List   (PRL)   in     the   respective   DHCP  messages   as   defined   in   [ RFC2131 ]   and   [ RFC2132 ] .     The  DHCP   client   MAY   initiate   a   new   DHCP   exchange   or  piggyback   on     other   DHCP   message   exchanges.   DHCP   client  handling   PRL   options   are     specified   in   [ RFC2131 ] ,  Section   4.4. 4.2.   Usage   of   EmergencyNumberList   Options   for  DHCPv6   The   requesting   and   sending   of   the     proposed  DHCPv6   options   follow   the   rules   for   DHCP   options   in   [RFC3315 ] . 4.2.1.   Mobile   Node   Behavior   The   mobile   node  MAY   request   an   EmergencyNumberList   according   to   the  scenarios   described   in   Section   4.1.1.   In   order   to  discover   an     EmergencyNumberList,   the   mobile   node   (DHCP  client)   MUST   include   an     EmergencyNumberList   Option   in  the   Option   Request   Option   (ORO)   in   the   respective     DHCP  messages   as   defined   in   [ RFC3315 ] .     The   DHCP   client  MAY   initiate   a   new   DHCP   exchange   or   piggyback   on   other  DHCP   message     exchanges.   DHCP   client-handling   ORO   options  are   specified   in   [ RFC3315 ] ,     Sections   17.1   and   18.1.

5G

In a further embodiment, a 5G solution is provided. In this embodiment,functionality includes:

-   -   Mobile device creates a secure tunnel with the non 3GPP network    -   Mobile Device receives NAS message from the non 3GPP network        containing a list of emergency numbers specific to the network        the Mobile device has registered with.

Additionally, Optional Functionality Includes

-   -   The emergency numbers can be further related to the network        slice (e.g. SST and optional SD) the Mobile Device has        registered with.

Changes are shown below in Table 12 in bold and underlining that addstext to 3GPP TS 23.501. The changes in Table 12 correspond to FIG. 7 :

TABLE 12 proposed in bold (item 7) changes that adds text to 3GPP TS23.501 4.12.2 Initial Registration via an untrusted non-3GPP Access Thisclause specifies how a UE can register to a 5G core network via anuntrusted non- 3GPP access network when the UE does not have a validsecurity context for this network, i.e. when the UE has not previouslyregistered with this network. It is based on the registration procedurespecified in clause 4.2.2.2. The procedure shown below shall beinitiated by the UE when it selects an N3IWF in a PLMN for which the UEdoes not have a valid security context. When the UE selects an N3IWF ina PLMN for which the UE has a valid security context, the UE shallinitiate instead the procedure specified in clause 4.12.2a. 1. The UE connects to an untrusted  non-3GPP access network with procedures  defined outside the scope of 3GPP and   is assigned an IP address. Any non-3GPP  authentication method can be used,   e.g. no authentication (in case of an open-  authentication WLAN), EAP with pre-shared   key, username/password, etc. When  the UE decides to attach to a 5G core network,   the UE discovers the IP address of   N3IWF in a 5G PLMN as described   in TS 23.501 [2], clause TBD. 2. The UE proceeds with the establishment  of an IPsec SA with the N3IWF by  initiating the IKEv2 signalling procedure   according to RFC 7296 [3] and  RFC 5998 [4]. After step 2a all subsequent   IKEv2 messages are encrypted and  integrity protected. In step 2b the UE shall   include a UE identity (e.g. Permanent  User Id or Temporary User Id) but shall   not include the AUTH payload in order to  trigger an EAP-based authentication, as   specified in RFC 7296 [3]. The N3IWF  behaves as an EAP authenticator and   retrieves the Network Access Identifier (NAI)  [5] of the UE in steps 2c, 2d. In step 2d the   UE may include a 3GPP-specific  Vendor Id (VID) payload which contains   registration parameters, such as a  registration type (defined in clause 4.2.2.2.2),   and network slice selection  assistance information (NSSAI). The NSSAI   is specified in TS 23.501 [2],   clause 5.15, and is optionally included in the registration parameters.  3......   Editor's   note:  It   is   FFS   if   GRE   encapsulation     for   NAS   messages   is  required.  7. Via the established signalling IPsec SA, ‘the N3IWF shall send to the UE the NAS  SMC Request received from the AMF in step    6b  optionally  including   a   list   of    emergency   numbers   using   the   format     as   described   in   X.   The   emergency    numbers   may   be  associated   with   the      Network   Slice   (e.g.   the   SST)   the  UE   has    registered   with.  The UE responds with a   NAS SMC Complete message, which  shall be forwarded by the N3IWF to the   AMF within an N2 UL NAS Transport   message. 8. The AMF shall send a NAS Registration   Accept message to the N3IWF, within an  N2 Initial Context Setup Request, which   shall be forwarded to the UE via the  established signalling IPsec SA.   Finally, the UE shall respond with a NAS  Registration Complete message which   shall be forwarded by the N3IWF to the  AMF within an N2 Initial Context Setup Response. Note: The Networkslice could be indicated by the inclusion of S-NSSAI

In Table 12 above, in step 7 X could be any of the codings as describedin the present disclosure.

Specifically, according to FIG. 7 a UE 710 communicates through aUntrusted non-3GPP Access Network 712.

Further, 5G elements include N3IWF 714, AMF/SEAF 716 and AUSF 718.

As seen in block 720, the UE 710 connects to an Untrusted non-3GPPAccess Network 712 and is allocated an IP address.

Further, as seen in block 722, the UE 710 discovers the IP address ofN3IWF 714.

After discovering the IP address, UE 710 and N3IWF 714 exchangeIKE_SA_INIT messages 730. Specifically, IKE_AUTH Req 732 is sent from UE710 to N3IWF 714, and may contain a user equipment identifier and a “noAUTH” indication.

In response N3IWF 714 sends a message 734 which may contain anEAP-REQ/Identity.

The UE 710 responds to message 734 with an IKE_AUTH Request 736 whichcontains EAP-Response/Identity along with registration parameters.

Based on request 736, N3IWF 714 performs an AMF selection, as shown byblock 740. The N3IWF 714 may then send an initial UE message 742.Message 742 may contain a registration request, registration parametersand EAP-Response/Identity.

On receipt of message 742 AMF/SEAF 716 may perform an AUSF selection asshown by block 744.

Once AUSF 718 is selected, AMF/SEAF 716 sends an authentication request746 to AUSF 718.

AUSF 718 may then perform mutual EAP-based authentication with UE 710,as shown by block 750. In particular, AUSF 718 sends an authenticationresponse 752 to AMF/SEAF 716. The AMF/SEAF 716 then sends a DL NASTransport message 754 containing message 752 to N3IWF 714.

N3IWF 714 then sends an IKE_AUTH Response 756 with the EAP to UE 710.

UE 710 then provides an IKE_AUTH Request 760 with the EAP back to N3IWF714.

N3IWF 714 then provides an UL NAS Transport with an authenticationresponse in message 762 back to AMF/SEAF 716. An authentication requestis then provided back to AUSF 718 as shown by message 764. AUSF 718verifies the request and provides an authentication response 766indicating EAP-Success along with security keys to AMF/SEAF 716.

AMF/SEAF 716 then provides DL NAS Transport in message 768 to N3IWF 714.

Message 768 contains the EAP-Success indicator, the N3IWF security keyand an SMC Request.

N3IWF 714 then provides an IKE_AUTH Response 770 back to UE 710.

Subsequently, the IPsec SA is established, as shown by arrow 772.

N3IWF 714 can then send an NAS over IPsec message providing an SMCRequest 780. Message 780 may optionally provide a list of emergencynumbers as indicated in Table 12 above.

In response to message 780, UE 710 provides an SMC Complete message 782back to N3IWF 714. The N3IWF 714 may then provide an SMC Completemessage 784 to AMF/SEAF 716, for example using an uplink NAS Transport.

AMF/SEAF 716 may then perform an initial context set up request inmessage 786, indicating Registration Accept. Message 786 is provided toN3IWF 714.

On receipt of message 786, N3IWF 714 provides a Registration AcceptMessage 788 to UE 710. UE 710 may then provide a Registration Complete790 back to N3IWF 714.

N3IWF 714 then provides an Initial Context Setup Response Message 792back to the AMF/SEAF 716, indicating Registration Complete.

PCO

In a further embodiment, a Mobile Device sends a message optionallycontaining an indication that it requires “emergencynumberlist”. TheMobile Device receives a message back containing “emergencynumberlist”,wherein the emergencynumberlist comes back in an EAP response, andwherein the emergencynumberlist is in a Protocol Configuration Option.

PCO information, as described above, can be contained within EAPmessages. This solution describes how an emergencynumberlist can becoded using PCO in an EAP response message to the UE. Equally the PCOcould be encoded in an ANQP response.

Table 13 below shows an example implementation in which proposedmodifications are indicated by the underlined text:

TABLE 13 Proposed modifications to 3GPP TS 24.008 3GPP TS 24.008 Section10.5.6.3 Protocol configuration options .... Table 10.5.154/3GPP TS 24.008: Protocol  configuration options information element  Configuration protocol (octet 3)   Bits   3 2 1  0 0 0 PPP for use with IP PDP    type or IP PDN type (see  3GPP TS 24.301 [120])   All other values are interpreted as PPP   in this version of the protocol.   After octet 3, i.e. from octet 4   to octet z, two logical lists are defined:  - the Configuration protocol    options list (octets 4 to w), and  - the Additional parameters    list (octets w+1 to z).  Configuration protocol options    list (octets 4 to w)   .......  ....   MS to network direction:   ....  - 0010H (IPv4 Link MTU Request);   - 0011H (MS support of Local    address in TFT indicator);   - 0012H (emergencynumberlist); and  - FF00H to FFFFH reserved    for operator specific use.  Network to MS direction:   ......   - 0010H (IPv4 Link MTU);  - 0011H (Network support of Local    address in TFT indicator);  - 0012H emergencynumberlist;   - FF00H to FFFFH reserved   for operator specific use.......

Possible encodings of emergencynumberlist are described above.

The network elements and mobile devices described above may be anycomputing device. Such computing device or network node may include anytype of electronic device, including but not limited to, mobile devicessuch as smartphones or cellular telephones. Examples can further includefixed or mobile devices, such as internet of things devices, endpoints,home automation devices, medical equipment in hospital or homeenvironments, inventory tracking devices, environmental monitoringdevices, energy management devices, infrastructure management devices,vehicles or devices for vehicles, fixed electronic devices, amongothers.

One simplified block diagram of a computing device is shown with regardto FIG. 8 .

In FIG. 8 , device 810 includes a processor 820 and a communicationssubsystem 830, where the processor 820 and communications subsystem 830cooperate to perform the methods of the embodiments described above.

Processor 820 is configured to execute programmable logic, which may bestored, along with data, on device 810, and shown in the example of FIG.8 as memory 840. Memory 840 can be any tangible, non-transitory computerreadable storage medium. The computer readable storage medium may be atangible or in transitory/non-transitory medium such as optical (e.g.,CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, solidstate drive, or other memory known in the art.

Alternatively, or in addition to memory 840, device 810 may access dataor programmable logic from an external storage medium, for examplethrough communications sub system 830.

Communications subsystem 830 allows device 810 to communicate with otherdevices or network elements.

Communications between the various elements of device 810 may be throughan internal bus 860 in one embodiment. However, other forms ofcommunication are possible and are within the scope of the presentdisclosure.

Further, one example mobile device is described below with regard toFIG. 9 .

Mobile device 900 may comprise a two-way wireless communication devicehaving voice and data communication capabilities. Mobile device 900generally has the capability to communicate with other computer systemson the Internet. Depending on the exact functionality provided, themobile device may be referred to as a data messaging device, a two-waypager, a wireless e-mail device, a cellular telephone with datamessaging capabilities, a wireless Internet appliance, a wirelessdevice, a user equipment, a smartphone, a tablet, a laptop, a notebook,or a data communication device, as non-limiting examples.

Where mobile device 900 is enabled for two-way communication, it mayincorporate a communication subsystem 911, including a receiver 912 anda transmitter 914, as well as associated components such as one or moreantenna elements 916 and 918, local oscillators (LOs) 913, and aprocessing module such as a digital signal processor (DSP) 920. As willbe apparent to those skilled in the field of communications, theparticular design of the communication subsystem 911 will be dependentupon the communication network in which the device is intended tooperate.

Network access requirements will also vary depending upon the type ofnetwork 919. In some networks network access is associated with asubscriber or user of mobile device 900. A mobile device may require aremovable user identity module (RUIM) or a subscriber identity module(SIM) card in order to operate on a network. The SIM/RUIM interface 944is normally similar to a card-slot into which a SIM/RUIM card can beinserted and ejected. The SIM/RUIM card can have memory and hold manykey configurations 951, and other information 953 such asidentification, and subscriber related information. Without a SIM card,the mobile device may still be capable of limited functionality,including placing an emergency call.

When required network registration or activation procedures have beencompleted, mobile device 900 may send and receive communication signalsover the network 919. As illustrated in FIG. 9 , network 919 can includemultiple base stations communicating with the mobile device.

Signals received by antenna 916 through communication network 919 areinput to receiver 912, which may perform such common receiver functionsas signal amplification, frequency down conversion, filtering, channelselection and the like. Analog to digital (A/D) conversion of a receivedsignal allows more complex communication functions such as demodulationand decoding to be performed in the DSP 920. In a similar manner,signals to be transmitted are processed, including modulation andencoding for example, by DSP 920 and input to transmitter 914 fordigital to analog (D/A) conversion, frequency up conversion, filtering,amplification and transmission over the communication network 919 viaantenna 918. DSP 920 not only processes communication signals, but alsoprovides for receiver and transmitter control. For example, the gainsapplied to communication signals in receiver 912 and transmitter 914 maybe adaptively controlled through automatic gain control algorithmsimplemented in DSP 920.

Mobile device 900 generally includes a processor 938 which controls theoverall operation of the device. Communication functions, including dataand optionally voice communications, are performed through communicationsubsystem 911. Processor 938 also interacts with further devicesubsystems such as the display 922, flash memory 924, random accessmemory (RAM) 926, auxiliary input/output (I/O) subsystems 928, serialport 930, one or more keyboards or keypads 932, speaker 934, microphone936, other communication subsystem 940 such as a short-rangecommunications subsystem and any other device subsystems, such assensors, generally designated as 942. Serial port 930 may include a USBport or other port known to those in the art.

Some of the subsystems shown in FIG. 9 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 932 and display922, for example, may be used for both communication-related functions,such as entering a text message for transmission over a communicationnetwork, and device-resident functions such as a calculator or tasklist.

Operating system software used by the processor 938 may be stored in apersistent store such as flash memory 924, which may instead be aread-only memory (ROM) or similar storage element (not shown). Thoseskilled in the art will appreciate that the operating system, specificdevice applications, or parts thereof, may be temporarily loaded into avolatile memory such as RAM 926. Received communication signals may alsobe stored in RAM 926.

As shown, flash memory 924 can be segregated into different areas forboth computer programs 958 and program data storage 950, 952, 954 and956. These different storage types indicate that each program canallocate a portion of flash memory 924 for their own data storagerequirements. On such program data storage may include a credentialvault.

Processor 938, in addition to its operating system functions, may enableexecution of software applications on the mobile device. A predeterminedset of applications that control basic operations, including at leastdata and voice communication applications for example, will normally beinstalled on mobile device 900 during manufacturing. Other applicationscould be installed subsequently or dynamically.

Applications and software may be stored on any computer readable storagemedium. The computer readable storage medium may be a tangible orintransitory/non-transitory medium such as optical (e.g., CD, DVD,etc.), magnetic (e.g., tape) or other memory known in the art.

One software application may be a personal information manager (PIM)application having the ability to organize and manage data itemsrelating to the user of the mobile device such as, but not limited to,e-mail, calendar events, voice mails, appointments, and task items.Further applications, including productivity applications, social mediaapplications, games, among others, may also be loaded onto the mobiledevice 900 through the network 919, an auxiliary I/O subsystem 928,serial port 930, short-range communications subsystem or any othersuitable subsystem 942, and installed by a user in the RAM 926 or anon-volatile store (not shown) for execution by the processor 938. Suchflexibility in application installation increases the functionality ofthe device and may provide enhanced on-device functions,communication-related functions, or both.

In a data communication mode, a received signal such as a text messageor web page download will be processed by the communication subsystem911 and input to the processor 938, which may further process thereceived signal for output to the display 922, or alternatively to anauxiliary I/O device 928.

A user of mobile device 900 may also compose data items such as emailmessages for example, using the keyboard 932, which may be a completealphanumeric keyboard or telephone-type keypad, either physical orvirtual, among others, in conjunction with the display 922 and possiblyan auxiliary I/O device 928. Such composed items may then be transmittedover a communication network through the communication subsystem 911.

For voice communications which are optional, overall operation of mobiledevice 900 is similar, except that received signals may typically beoutput to a speaker 934 and signals for transmission may be generated bya microphone 936. Alternative voice or audio I/O subsystems, such as avoice message recording subsystem, may also be implemented on mobiledevice 900. Although voice or audio signal output is preferablyaccomplished primarily through the speaker 934, display 922 may also beused to provide an indication of the identity of a calling party, theduration of a voice call, or other voice call related information forexample.

Serial port 930 in FIG. 9 may be implemented in a mobile device forwhich synchronization with a user's desktop computer (not shown) may bedesirable, but is an optional device component. Such a port 930 mayenable a user to set preferences through an external device or softwareapplication and may extend the capabilities of mobile device 900 byproviding for information or software downloads to mobile device 900other than through a wireless communication network. As will beappreciated by those skilled in the art, serial port 930 can further beused to connect the mobile device to a computer to act as a modem or forcharging a battery on the mobile device.

Other communications subsystems 940, such as a short-rangecommunications subsystem, is a further optional component which mayprovide for communication between mobile device 900 and differentsystems or devices, which need not necessarily be similar devices. Forexample, the subsystem 940 may include an infrared device and associatedcircuits and components or a Bluetooth™ communication module to providefor communication with similarly enabled systems and devices. Subsystem940 may further include non-cellular communications such as WiFi orWiMAX, or near field communications.

The embodiments described herein are examples of structures, systems ormethods having elements corresponding to elements of the techniques ofthis application. This written description may enable those skilled inthe art to make and use embodiments having alternative elements thatlikewise correspond to the elements of the techniques of thisapplication. The intended scope of the techniques of this applicationthus includes other structures, systems or methods that do not differfrom the techniques of this application as described herein, and furtherincludes other structures, systems or methods with insubstantialdifferences from the techniques of this application as described herein.

While operations are depicted in the drawings in a particular order,this should not be understood as requiring that such operations beperformed in the particular order shown or in sequential order, or thatall illustrated operations be performed, to achieve desirable results.In certain circumstances, multitasking and parallel processing may beemployed. Moreover, the separation of various system components in theimplementation descried above should not be understood as requiring suchseparation in all implementations, and it should be understood that thedescribed program components and systems can generally be integratedtogether in a signal software product or packaged into multiple softwareproducts.

Also, techniques, systems, subsystems, and methods described andillustrated in the various implementations as discrete or separate maybe combined or integrated with other systems, modules, techniques, ormethods. Other items shown or discussed as coupled or directly coupledor communicating with each other may be indirectly coupled orcommunicating through some interface, device, or intermediate component,whether electrically, mechanically, or otherwise. Other examples ofchanges, substitutions, and alterations are ascertainable by one skilledin the art and may be made.

While the above detailed description has shown, described, and pointedout the fundamental novel features of the disclosure as applied tovarious implementations, it will be understood that various omissions,substitutions, and changes in the form and details of the systemillustrated may be made by those skilled in the art. In addition, theorder of method steps are not implied by the order they appear in theclaims.

When messages are sent to/from an electronic device, such operations maynot be immediate or from the server directly. They may be synchronouslyor asynchronously delivered, from a server or other computing systeminfrastructure supporting the devices/methods/systems described herein.The foregoing steps may include, in whole or in part,synchronous/asynchronous communications to/from thedevice/infrastructure. Moreover, communication from the electronicdevice may be to one or more endpoints on a network. These endpoints maybe serviced by a server, a distributed computing system, a streamprocessor, etc. Content Delivery Networks (CDNs) may also provide mayprovide communication to an electronic device. For example, rather thana typical server response, the server may also provision or indicate adata for content delivery network (CDN) to await download by theelectronic device at a later time, such as a subsequent activity ofelectronic device. Thus, data may be sent directly from the server, orother infrastructure, such as a distributed infrastructure, or a CDN, aspart of or separate from the system.

Typically, storage mediums can include any or some combination of thefollowing: a semiconductor memory device such as a dynamic or staticrandom access memory (a DRAM or SRAM), an erasable and programmableread-only memory (EPROM), an electrically erasable and programmableread-only memory (EEPROM) and flash memory; a magnetic disk such as afixed, floppy and removable disk; another magnetic medium includingtape; an optical medium such as a compact disk (CD) or a digital videodisk (DVD); or another type of storage device. Note that theinstructions discussed above can be provided on one computer-readable ormachine-readable storage medium, or alternatively, can be provided onmultiple computer-readable or machine-readable storage media distributedin a large system having possibly plural nodes. Such computer-readableor machine-readable storage medium or media is (are) considered to bepart of an article (or article of manufacture). An article or article ofmanufacture can refer to any manufactured single component or multiplecomponents. The storage medium or media can be located either in themachine running the machine-readable instructions, or located at aremote site from which machine-readable instructions can be downloadedover a network for execution.

In the foregoing description, numerous details are set forth to providean understanding of the subject disclosed herein. However,implementations may be practiced without some of these details. Otherimplementations may include modifications and variations from thedetails discussed above. It is intended that the appended claims coversuch modifications and variations.

Further, in some embodiment the clauses below may provide suchmodifications and variations.

AA. A method at a user equipment (UE) comprising: sending a requestmessage to a network node, the request message containing an indication;and receiving, at the user equipment, a response message, the responsemessage including a Uniform Resource Name (URN) including a countrycode.

AB. The method of clause AA, wherein the indication comprises an AccessNetwork Query Protocol (ANQP) Emergency Call Number element.

AC. The method of clause AA, wherein the URN comprises a namespacespecific string including at least one namespace identifier.

AD. The method of clause AC, wherein the at least one namespaceidentifier includes one or both of: the namespace identifier “3gpp” orthe namespace identifier “sos-anqp”.

AE. The method of clause AA wherein the URN further includes one or bothof: at least one emergency number; or at least one emergency call type.

AF. The method of clause AE wherein the at least one emergency call typeincludes a label “sos”.

AG. The method of clause AF wherein the label “sos” is followed by atleast one sub-label.

AH. The method of clause AG wherein the sub-label includes one of“police”, “ambulance”, “fire”, “marine”, or “mountain”.

AI. The method of clause AA, wherein the request message comprises anANQP request message.

AJ. The method of clause AA, wherein the response message comprises anANQP response message.

AK. The method of clause AA, wherein the URN has no emergency number,and wherein the receiving comprises overwriting a previously receivedlist having local emergency numbers with an empty list.

AL. The method of clause AA, further comprising: detecting that the URNhas no emergency number; detecting a previously received list forstoring local emergency numbers; and replacing the previously receivedlist with a list with no emergency number.

AM. The method of clause AA, further comprising: detecting that the URNhas no emergency number; and storing a list with no emergency number.

AN. The method of clause AA, wherein the country code comprises an MCC,and wherein the MCC indicates a portion of a Public Land Mobile Network(PLMN) code to which the emergency number, type or category informationapplies.

AO. A user equipment comprising: a processor; and a communicationssubsystem, wherein the user equipment is configured to: send a requestmessage to a network node, the request message containing an indication;and receive a response message, the response message including a UniformResource Name (URN) including a country code.

AP. The user equipment of clause AO, wherein the indication comprises anAccess Network Query Protocol (ANQP) Emergency Call Number element.

AQ. The user equipment of clause AO, wherein the URN comprises anamespace specific string including at least one namespace identifier.

AR. The user equipment of clause AP, wherein the at least one namespaceidentifier includes one or both of: the namespace identifier “3gpp” orthe namespace identifier “sos-anqp”.

AS. The user equipment of clause AO wherein the URN further includes oneor both of: at least one emergency number; or at least one emergencycall type.

AT. The user equipment of clause AS wherein the at least one emergencycall type includes a label “sos”.

AU. The user equipment of clause AT wherein the label “sos” is followedby at least one sub-label.

AV. The user equipment of clause AU wherein the sub-label includes oneof “police”, “ambulance”, “fire”, “marine”, or “mountain”.

AW. The user equipment of clause AO, wherein the request messagecomprises an ANQP request message.

AX. The user equipment of clause AO, wherein the response messagecomprises an ANQP response message.

AY. The user equipment of clause AO, wherein the URN has no emergencynumber, and wherein the user equipment is configured to receive byoverwriting a previously received list having local emergency numberswith an empty list.

AZ. A non-transitory computer readable medium for storing instructioncode which, when executed by a processor of a user equipment, causes theuser equipment to: send a request message to a network node, the requestmessage containing an indication; and receive a response message, theresponse message including a uniform resource name including an emptyemergency number list along with a country code.

BA. A method at a network element comprising: receiving a requestmessage from a user equipment, the request message containing anindication; and sending, to the user equipment, a response message, theresponse message including a Uniform Resource Name (URN) including acountry code.

BB. A network element comprising: a processor; and a communicationssubsystem, wherein the network element is configured to receive arequest message from a user equipment, the request message containing anindication; and send, to the user equipment, a response message, theresponse message including a Uniform Resource Name (URN) including acountry code.

BC. A non-transitory computer readable medium for storing instructioncode which, when executed by a processor of a network element, causesthe network element to receive a request message from a user equipment,the request message containing an indication; and send, to the userequipment, a response message, the response message including a UniformResource Name (URN) including a country code.

BD. A method at a network element for providing emergency codes using anon-Third Generation Partnership Project (3GPP) network, the methodcomprising: receiving a request message from a user equipment, therequest message containing an indication; and sending, to the userequipment, a response message, the response message including at leastone mobile country code (MCC), and the response message indicating anemergency number, type or category information, wherein the emergencynumber, type or category information is associated with the at least oneMCC, and wherein the at least one MCC indicates a portion of a PublicLand Mobile Network (PLMN) code to which the emergency number, type orcategory information applies.

BE. A network element for providing emergency codes using a non-ThirdGeneration Partnership Project (3GPP) network, the network elementcomprising: a processor; and a communications subsystem, wherein thenetwork element is configured to: receive a request message from a userequipment, the request message containing an indication; and send, tothe user equipment, a response message, the response message includingat least one mobile country code (MCC), and the response messageindicating an emergency number, type or category information, whereinthe emergency number, type or category information is associated withthe at least one MCC, and wherein the at least one MCC indicates aportion of a Public Land Mobile Network (PLMN) code to which theemergency number, type or category information applies.

BF. A non-transitory computer readable medium for storing instructioncode which, when executed by a processor of a network element, causesthe network element to receive a request message from a user equipment,the request message containing an indication; and send, to the userequipment, a response message, the response message including at leastone mobile country code (MCC), and the response message indicating anemergency number, type or category information, wherein the emergencynumber, type or category information is associated with the at least oneMCC, and wherein the at least one MCC indicates a portion of a PublicLand Mobile Network (PLMN) code to which the emergency number, type orcategory information applies.

1. A method using Internet Key Exchange Protocol version 2 (IKEv2)procedures at a user equipment for obtaining emergency numbers, themethod comprising: transmitting an IKEv2 request message comprising arequest for emergency number information to an evolved packet datagateway (ePDG); receiving, from the ePDG, an IKEv2 response message, theIKEv2 response message including an indicator of an empty list ofemergency numbers and a mobile country code (MCC); and in response tothe IKEv2 response message, overwriting a previously received list oflocal emergency numbers.
 2. The method of claim 1, wherein the IKEv2request message is an IKE_AUTH request.
 3. The method of claim 1,wherein the IKEv2 request message comprises a CFG_REQUEST configurationpayload.
 4. The method of claim 1, wherein the IKEv2 response message isan IKE_AUTH response.
 5. The method of claim 1, wherein the IKEv2response message comprises a CFG_REPLY configuration payload.
 6. A userequipment comprising: a processor; a communication subsystem, whereinthe user equipment is configured to: transmit an IKEv2 request messagecomprising a request for emergency number information to an evolvedpacket data gateway (ePDG); receive, from the ePDG, an IKEv2 responsemessage, the IKEv2 response message including an indicator of an emptylist of emergency numbers and a mobile country code (MCC); and inresponse to the IKEv2 response message, overwrite a previously receivedlist of local emergency numbers.
 7. The user equipment of claim 6,wherein the IKEv2 request message is an IKE_AUTH request.
 8. The userequipment of claim 6, wherein the IKEv2 request message comprises aCFG_REQUEST configuration payload.
 9. The user equipment of claim 6,wherein the IKEv2 response message is an IKE_AUTH response.
 10. The userequipment of claim 6, wherein the IKEv2 response message comprises aCFG_REPLY configuration payload.
 11. A non-transitory computer-readablemedium containing instructions which, when executed, cause a userequipment to perform operations comprising: transmitting an IKEv2request message comprising a request for emergency number information toan evolved packet data gateway (ePDG); receiving, from the ePDG, anIKEv2 response message, the IKEv2 response message including anindicator of an empty list of emergency numbers and a mobile countrycode (MCC); and in response to the IKEv2 response message, overwriting apreviously received list of local emergency numbers.
 12. Thenon-transitory computer-readable medium of claim 11, wherein the IKEv2request message is an IKE_AUTH request.
 13. The non-transitorycomputer-readable medium of claim 11, wherein the IKEv2 request messagecomprises a CFG_REQUEST configuration payload.
 14. The non-transitorycomputer-readable medium of claim 11, wherein the IKEv2 response messageis an IKE_AUTH response.
 15. The non-transitory computer-readable mediumof claim 11, wherein the IKEv2 response message comprises a CFG_REPLYconfiguration payload.